A Study of Modern Linux API Usage and Compatibility: What to Support When You’re Supporting

April 4, 2021 at 10:51 am
Paper Security System

EuroSys'16 Best Paper

link

This paper supports the author's following work, graphene(-SGX).

Targeted Interfaces (APIs)

  • System Calls
  • Proc Filesystem

Method

  • Measured the download and dependency data of packages in Ubuntu 15.04.
  • Statically analyzed what syscalls will be invoked in a package and what path will be accessed by a binary (hardcoded string)

Measurement

  • API Importance: A Metric for Individual APIs
  • Weighted Completeness: A System-Wide Metric (combined with #downloads)

Questions Answered

  • Which syscalls are more important than others?
  • Which syscalls can be deprecated? (some are rarely used)
  • Which syscalls should be supported for compatibility?

A Tale of Two Worlds: Assessing the Vulnerability of Enclave Shielding Runtimes

April 5, 2021 at 10:28 am
Attack Paper Research Security SGX

Paper

This paper analyzes the vulnerability space arising in Trusted Execution Environments (TEEs) when interfacing a trusted enclave application with untrusted, potentially malicious code. Considerable research and industry effort has gone into developing TEE runtime libraries with the purpose of transparently shielding enclave application code from an adversarial environment. However, our analysis reveals that shielding requirements are generally not well-understood in real-world TEE runtime implementations. We expose several sanitization vulnerabilities at the level of the Application Binary Interface (ABI) and the Application Programming Interface (API) that can lead to exploitable memory safety and side-channel vulnerabilities in the compiled enclave. Mitigation of these vulnerabilities is not as simple as ensuring that pointers are outside enclave memory. In fact, we demonstrate that state-of-the-art mitigation techniques such as Intel's edger8r, Microsoft's "deep copy marshalling", or even memory-safe languages like Rust fail to fully eliminate this attack surface. Our analysis reveals 35 enclave interface sanitization vulnerabilities in 8 major open-source shielding frameworks for Intel SGX, RISC-V, and Sancus TEEs. We practically exploit these vulnerabilities in several attack scenarios to leak secret keys from the enclave or enable remote code reuse. We have responsibly disclosed our findings, leading to 5 designated CVE records and numerous security patches in the vulnerable open-source projects, including the Intel SGX-SDK, Microsoft Open Enclave, Google Asylo, and the Rust compiler.

ABI vulnerabilities

  • Entry status flags sanitization

  • Entry stack pointer restore

  • Exit register leakage

API vulnerabilities

  • Missing pointer range check

  • Null-terminated string handling

  • Integer overflow in range check

  • Incorrect pointer range check

  • Double fetch untrusted pointer

  • Ocall return value not checked

  • Uninitialized padding leakage

Targets

  • SGX-SDK

  • OpenEnclave

  • Graphene

  • SGX-LKL

  • Rust-EDP

  • Asylo

  • Keystone

  • Sancus

that legacy applications may also make implicit assumptions on the validity of argv and envp pointers, which are not the result of system calls.

BesFS_overview.png

April 4, 2021 at 10:30 am

BesFS: A POSIX Filesystem for Enclaves with a Mechanized Safety Proof

April 4, 2021 at 10:31 am
Formal Paper Research Security SGX System

Filesystem + Formal Method + SGX

New trusted computing primitives such as Intel SGX have shown the feasibility of running user-level applications in enclaves on a commodity trusted processor without trusting a large OS. However, the OS can still compromise the integrity of an enclave by tampering with the system call return values. In fact, it has been shown that a subclass of these attacks, called Iago attacks, enables arbitrary logic execution in enclave programs. Existing enclave systems have very large TCB and they implement ad-hoc checks at the system call interface which are hard to verify for completeness. To this end, we present BesFS—the first filesystem interface which provably protects the enclave integrity against a completely malicious OS. We prove 167 lemmas and 2 key theorems in 4625 lines of Coq proof scripts, which directly proves the safety properties of the BesFS specification. BesFS comprises of 15 APIs with compositional safety and is expressive enough to support 31 real applications we test. BesFS integrates into existing SGX-enabled applications with minimal impact to TCB. BesFS can serve as a reference implementation for hand-coded API checks.

BlackMirror: Preventing Wallhacks in 3D Online FPS Games

April 4, 2021 at 10:34 am
Defense Paper Research Security SGX

PDF

SGX to protect GPU then prevent cheating

Abstract

Online gaming, with a reported 152 billion US dollar market, is immensely popular today. One of the critical issues in multiplayer online games is cheating, in which a player uses an illegal methodology to create an advantage beyond honest game play. For example, wallhacks, the main focus of this work, animate enemy objects on a cheating player's screen, despite being actually hidden behind walls (or other occluding objects). Since such cheats discourage honest players and cause game companies to lose revenue, gaming companies deploy mitigation solutions alongside game applications on the player's machine. However, their solutions are fundamentally flawed since they are deployed on a machine where the attacker has absolute control.

BranchShadowing2.png

April 4, 2021 at 10:55 am

BranchShadowing3.png

April 4, 2021 at 10:55 am

COIN Attacks: On Insecurity of Enclave Untrusted Interfaces in SGX

April 5, 2021 at 10:02 am
Attack Paper Research Security SGX

Intel SGX is a hardware-based trusted execution environment (TEE), which enables an application to compute on confidential data in a secure enclave. SGX assumes a powerful threat model, in which only the CPU itself is trusted; anything else is untrusted, including the memory, firmware, system software, etc. An enclave interacts with its host application through an exposed, enclave-specific, (usually) bi-directional interface. This interface is the main attack surface of the enclave. The attacker can invoke the interface in any order and inputs. It is thus imperative to secure it through careful design and defensive programming.

In this work, we systematically analyze the attack models against the enclave untrusted interfaces and summarized them into the COIN attacks -- Concurrent, Order, Inputs, and Nested. Together, these four models allow the attacker to invoke the enclave interface in any order with arbitrary inputs, including from multiple threads. We then build an extensible framework to test an enclave in the presence of COIN attacks with instruction emulation and concolic execution. We evaluated ten popular open-source SGX projects using eight vulnerability detection policies that cover information leaks, control-flow hijackings, and memory vulnerabilities. We found 52 vulnerabilities. In one case, we discovered an information leak that could reliably dump the entire enclave memory by manipulating the inputs. Our evaluation highlights the necessity of extensively testing an enclave before its deployment.

Target

To find vulnerabilities of SGX applications in four models:

  • Concurrent calls: multithread, race condition, improper lock…

  • Order: assumes the calling sequence

  • Input manipulation: bad OCALL return val & ECALL arguments

  • Nested calls: calling OCALL that invokes ECALL, not implemented

Design & Method

The design of COIN:

  • Emulation: QEMU

  • Symbolic execution: Triton (backed by z3)

  • Policy-based vulnerability discovery

Results

COIN uses 8 policies to find the potential vulnerabilities:

  • Heap info leak

  • Stack info leak

  • Ineffectual condition

  • Use after free

  • Double free

  • Stack overflow

  • Heap overflow

  • Null pointer dereference

Review

Strength

  • Symbolic execution + emulation

  • Policies can be configurable

  • Real world problems

Weakness

  • nested call left unimplemented

  • May not be powerful enough to deal with complicate situations

  • Policies are mainly at relatively low-level

Controlled-Channel Attacks: Deterministic SideChannels for Untrusted Operating Systems

April 4, 2021 at 11:20 am
Attack Iago Paper Research Security SGX SideChannel

S&P' 15

The presence of large numbers of security vulnerabilities in popular feature-rich commodity operating systems has inspired a long line of work on excluding these operating systems from the trusted computing base of applications, while retaining many of their benefits. Legacy applications continue to run on the untrusted operating system, while a small hyper visor or trusted hardware prevents the operating system from accessing the applications' memory. In this paper, we introduce controlled-channel attacks, a new type of side-channel attack that allows an untrusted operating system to extract large amounts of sensitive information from protected applications on systems like Overshadow, Ink Tag or Haven. We implement the attacks on Haven and Ink Tag and demonstrate their power by extracting complete text documents and outlines of JPEG images from widely deployed application libraries. Given these attacks, it is unclear if Over shadow's vision of protecting unmodified legacy applications from legacy operating systems running on off-the-shelf hardware is still tenable.

The key intuition is to exploit the fact that a regular applicationusually shows different patterns in control transfers or data accesses when the sensitive data it is processing are different.

  • Induce Page Fault
  • Recognize page access -> control/data flow
  • Recover sensitive info

Mitigation

Data-Oriented Programming: On the Expressiveness of Non-Control Data Attacks

April 4, 2021 at 11:48 am
Attack Paper Research Security System

S&P'16

As control-flow hijacking defenses gain adoption, it is important to understand the remaining capabilities of adversaries via memory exploits. Non-control data exploits are used to mount information leakage attacks or privilege escalation attacks program memory. Compared to control-flow hijacking attacks, such non-control data exploits have limited expressiveness, however, the question is: what is the real expressive power of non-control data attacks? In this paper we show that such attacks are Turing-complete. We present a systematic technique called data-oriented programming (DOP) to construct expressive non-control data exploits for arbitrary x86 programs. In the experimental evaluation using 9 programs, we identified 7518 data-oriented x86 gadgets and 5052 gadget dispatchers, which are the building blocks for DOP. 8 out of 9 real-world programs have gadgets to simulate arbitrary computations and 2 of them are confirmed to be able to build Turing-complete attacks. We build 3 end-to-end attacks to bypass randomization defenses without leaking addresses, to run a network bot which takes commands from the attacker, and to alter the memory permissions. All the attacks work in the presence of ASLR and DEP, demonstrating how the expressiveness offered by DOP significantly empowers the attacker.

There are no function call gadgets in data-oriented programming, as it does not change the control data.

  • Operate on data to achieve arbitrary computation

delegatee_centrally.png

April 4, 2021 at 11:44 am

delegatee_p2p.png

April 4, 2021 at 11:44 am

DelegaTEE: Brokered Delegation Using Trusted Execution Environments

April 4, 2021 at 11:45 am
Application Paper Research Security SGX

USENIX

We introduce a new concept called brokered delegation. Brokered delegation allows users to flexibly delegate credentials and rights for a range of service providers to other users and third parties. We explore how brokered delegation can be implemented using novel trusted execution environments (TEEs). We introduce a system called DelegaTEE that enables users (Delegatees) to log into different online services using the credentials of other users (Owners). Credentials in DelegaTEE are never revealed to Delegatees and Owners can restrict access to their accounts using a range of rich, contextually dependent delegation policies.

DelegaTEE fundamentally shifts existing access control models for centralized online services. It does so by using TEEs to permit access delegation at the user's discretion. DelegaTEE thus effectively reduces mandatory access control (MAC) in this context to discretionary access control (DAC). The system demonstrates the significant potential for TEEs to create new forms of resource sharing around online services without the direct support from those services.

We present a full implementation of DelegaTEE using Intel SGX and demonstrate its use in four real-world applications: email access (SMTP/IMAP), restricted website access using a HTTPS proxy, e-banking/credit card, and a third-party payment system (PayPal).

  • Account sharing: delegate the credentials to other users securely
  • Centrally and P2P

Dynamic Binary Translation for SGX Enclaves (Ratel)

April 4, 2021 at 10:51 am
Paper Research Security SGX

Old version: Binary Compatibility For SGX Enclaves

Paper Code

Yet another middleware to support unmodified binary to run in SGX enclave. This is done through dynamically rewrite binary inside the encalve.

Enclaves, such as those enabled by Intel SGX, offer a hardware primitive for shielding user-level applications from the OS. While enclaves are a useful starting point, code running in the enclave requires additional checks whenever control or data is transferred to/from the untrusted OS. The enclave-OS interface on SGX, however, can be extremely large if we wish to run existing unmodified binaries inside enclaves. This paper presents Ratel, a dynamic binary translation engine running inside SGX enclaves on Linux. Ratel offers complete interposition, the ability to interpose on all executed instructions in the enclave and monitor all interactions with the OS. Instruction-level interposition offers a general foundation for implementing a large variety of inline security monitors in the future.

We take a principled approach in explaining why complete interposition on SGX is challenging. We draw attention to 5 design decisions in SGX that create fundamental trade-offs between performance and ensuring complete interposition, and we explain how to resolve them in the favor of complete interposition. To illustrate the utility of the Ratel framework, we present the first attempt to offer binary compatibility with existing software on SGX. We report that Ratel offers binary compatibility with over 200 programs we tested, including micro-benchmarks and real applications such as Linux shell utilities. Runtimes for two programming languages, namely Python and R, tested with standard benchmarks work out-of-the-box on Ratel without any specialized handling.

Emilia: Catching Iago in Legacy Code

April 4, 2021 at 10:34 am
Attack Fuzz Paper Research Security SGX

PDF

Abstract

There has been interest in mechanisms that enable the secure use of legacy code to implement trusted code in a Trusted Execution Environment (TEE), such as Intel SGX. However, because legacy code generally assumes the presence of an operating system, this naturally raises the spectre of Iago attacks on the legacy code. We observe that not all legacy code is vulnerable to Iago attacks and that legacy code must use return values from system calls in an unsafe way to have Iago vulnerabilities.

Based on this observation, we develop Emilia, which automatically detects Iago vulnerabilities in legacy applications by fuzzing applications using system call return values. We use Emilia to discover 51 Iago vulnerabilities in 17 applications, and find that Iago vulnerabilities are widespread and common. We conduct an in-depth analysis of the vulnerabilities we found and conclude that while common, the majority (82.4%) can be mitigated with simple, stateless checks in the system call forwarding layer, while the rest are best fixed by finding and patching them in the legacy code. Finally, we study and evaluate different trade-offs in the design of Emilia.

  • Target: SGX Applications running inside a middleware
  • Method: Fuzzing
  • Tool: strace (to intercept syscall return value)

Fuzzing Strategies

  1. Target selection (syscalls)
  2. Extract branch conditions depending on the return value from syscalls
  3. Random/valid/invalid return values
  4. Different return fields

Evaluation

to be continued

graphene_arch.png

April 3, 2021 at 10:20 pm

GrapheneSGX

April 3, 2021 at 10:25 pm
Paper Research SGX System

Graphene-SGX: A Practical Library OS for Unmodified Applications on SGX

Paper Code

LibOS in enclave + unmodified binary

Intel SGX hardware enables applications to protect themselves from potentially-malicious OSes or hypervisors. In cloud computing and other systems, many users and applications could benefit from SGX. Unfortunately, current applications will not work out-of-the-box on SGX. Although previous work has shown that a library OS can execute unmodified applications on SGX, a belief has developed that a library OS will be ruinous for performance and TCB size, making application code modification an implicit prerequisite to adopting SGX.

This paper demonstrates that these concerns are exaggerated, and that a fully-featured library OS can rapidly deploy unmodified applications on SGX with overheads comparable to applications modified to use “shim” layers. We present a port of Graphene to SGX, as well as a number of improvements to make the security benefits of SGX more usable, such as integrity support for dynamically-loaded libraries, and secure multi-process support. Graphene-SGX supports a wide range of unmodified applications, including Apache, GCC, and the R interpreter. The performance overheads of Graphene- SGX range from matching a Linux process to less than 2× in most single-process cases; these overheads are largely attributable to current SGX hardware or missed opportunities to optimize Graphene internals, and are not necessarily fundamental to leaving the application unmodified. Graphene-SGX is open-source and has been used concurrently by other groups for SGX research.

  • Graphene-SGX assumes trusted binary, so it cannot protect enclave from malicious code/vulnerable code
  • Graphene-SGX loads its enclave first, and let the enclave then load the so-called unmodified binary
  • Interfaces are re-implemented in LibOS or export to the OS (Ocall)
  • To improve performance, some Ocalls can be exitless. This is implemented through writing the arguments outside the enclave at a specific location (ocall stack) and the outside code can help execute with these args.

Inferring Fine-grained Control Flow Inside SGX Enclaves with Branch Shadowing

April 4, 2021 at 10:55 am
Attack Paper Research Security SGX SideChannel

Paper

  • Exploits BPU(Branch-prediction Unit)
  • Train BPU to mispredict in a shadow program and observe side-channel

Intel has introduced a hardware-based trusted execution environment, Intel Software Guard Extensions (SGX), that provides a secure, isolated execution environment, or enclave, for a user program without trusting any underlying software (e.g., an operating system) or firmware. Researchers have demonstrated that SGX is vulnerable to a page-fault-based attack. However, the attack only reveals page-level memory accesses within an enclave.

In this paper, we explore a new, yet critical, sidechannel attack, branch shadowing, that reveals fine-grained control flows (branch granularity) in an enclave. The root cause of this attack is that SGX does not clear branch history when switching from enclave to non-enclave mode, leaving fine-grained traces for the outside world to observe, which gives rise to a branch-prediction side channel. However, exploiting this channel in practice is challenging because 1) measuring branch execution time is too noisy for distinguishing fine-grained control-flow changes and 2) pausing an enclave right after it has executed the code block we target requires sophisticated control. To overcome these challenges, we develop two novel exploitation techniques: 1) a last branch record (LBR)-based history-inferring technique and 2) an advanced programmable interrupt controller (APIC)-based technique to control the execution of an enclave in a fine-grained manner. An evaluation against RSA shows that our attack infers each private key bit with 99.8% accuracy. Finally, we thoroughly study the feasibility of hardware-based solutions (i.e., branch history flushing) and propose a software-based approach that mitigates the attack.

Matel Music

April 4, 2021 at 5:22 pm

MetaTiddler

April 3, 2021 at 10:39 pm
Artifact

记录一下折腾这个笔记的过程

现在我采用的方案是 TiddlyWiki Server 的目录放在我的 Github Pages 主页中,然后每次commit之前重新生成一个 html 链接在主站上面。

插件

我使用了一些插件来支持markdown, LaTeX 等常用组件。

Cheat Sheet

  • List all under a tag:<<list-links "[tag[SGX]]">>

  • List tiddlers having two tags simultaneously: <<list-links "[tag[SGX]tag[Paper]]">>

PapersByFields

April 3, 2021 at 8:46 pm
CS Research

PARTEMU: Enabling Dynamic Analysis of Real-World TrustZone Software Using Emulation

April 5, 2021 at 10:04 am
Attack Fuzz Paper Research Security System TrustZone

PartEmu

  • USENIX Security 2020

  • Paper

  • Source code unavailable

Traditional TrustZone OSes and Applications is not easy to fuzz because they cannot be instrumented or modified easily in the original hardware environment. So to emulate them for fuzzing purpose.

Targets

  • Emulate TrustZone OSes(TZOS) and Trusted Applications (TAs)

  • Abstract and reimplement a subset of hardware/software interfaces

  • Fuzz these components

  • TZOSes: QSEE, Huawei, OPTEE, Kinibi, TEEGRIS(Samsung) & TAs

Design & Method

  • Re-host the TZOS frimware

  • Choose the components to reuse/emulate carefully

    • Bootloader

    • Secure Monitor

    • TEE driver and TEE userspace

    • MMIO registers (easy to emulate)

Tools

  • TriforceAFL + QEMU

  • Manually written Interfaces

Results

Emulations works well. For upgraded TZOSes, only a few efforts are needed for compatibility.

TAs

Challenges

  • Identifying the fuzzed target

  • Result stability (migrate to hardware, reproducibility)

  • Randomness

ClassVulnerability TypesCrashes
AvailabilityNull-pointer dereferences9
Insufficient shared memory crashes10
Other8
ConfidentialityRead from attacker-controlled pointer to shared memory8
Read from attacker-controlled0
OOB buffer length to shared memory
IntegrityWrite to secure memory using attacker-controlled pointer11
Write to secure memory using2
attacker-controlled OOB buffer length

Just like the previous paper, the main causes of the crashes can be attributed to:

  • Assumptions of Normal-World Call Sequence

  • Unvalidated Pointers from Normal World

  • Unvalidated Types

TZOSes

  • Normal-World Checks

  • Assumptions of Normal-World Call Sequence

Review

Strength

  • Solid work

  • Efforts taken to run TZOS and TA in emulation environment

  • Acceptable performance

Weakness

  • Low coverage

  • Crashes -X-> vulnerabilities

SecurityPapersByTopic

April 5, 2021 at 10:06 am
Research Security

See through Walls: Detecting Malware in SGX Enclaves with SGX-Bouncer

April 4, 2021 at 10:34 am
Defense Paper Research Security SGX TODO

PDF

Intel Software Guard Extensions (SGX) offers strong confidentialityand integrity protection to software programs running in untrustedoperating systems. Unfortunately, SGX may be abused by attackersto shield suspicious payloads and conceal misbehaviors in SGXenclaves, which cannot be easily detected by existing defense solu-tions. There is no comprehensive study conducted to characterizemalicious enclaves. In this paper, we present the first systematicstudy that scrutinizes all possible interaction interfaces betweenenclaves and the outside (i.e., cache-memory hierarchy, host vir-tual memory, and enclave-mode transitions), and identifies sevenattack vectors. Moreover, we proposeSGX-Bouncer, a detectionframework that can detect these attacks by leveraging multifariousside-channel observations and SGX-specific features. We conductempirical evaluations with existing malicious SGX applications,which suggestsSGX-Bouncercan effectively detect various abnor-mal behaviors from malicious enclaves.

SGX Application Papers

April 4, 2021 at 10:27 am
Research Security SGX

SGX Middleware (Papers)

April 5, 2021 at 9:35 am
Research Security SGX

Middlewares

Container-like

Language-specific

SDK/API/Runtimes

Parallel

Attacks

SGX Papers

April 5, 2021 at 2:11 pm
Iago Research Security SGX

SGXCacheAttack.png

April 4, 2021 at 11:10 am

Software Grand Exposure: SGX Cache Attacks Are Practical

April 4, 2021 at 11:11 am
Attack Paper Research Security SGX SideChannel

WOOT'17

Intel SGX isolates the memory of security-critical applications from the untrusted OS. However, it has been speculated that SGX may be vulnerable to side-channel attacks through shared caches. We developed new cache attack techniques customized for SGX. Our attack differs from other SGX cache attacks in that it is easy to deploy and avoids known detection approaches. We demonstrate the effectiveness of our attack on two case studies: RSA decryption and genomic processing. While cache timing attacks against RSA and other cryptographic operations can be prevented by using appropriately hardened crypto libraries, the same cannot be easily done for other computations, such as genomic processing. Our second case study therefore shows that attacks on non-cryptographic but privacy sensitive operations are a serious threat. We analyze countermeasures and show that none of the known defenses eliminates the attack.

  • L1 cache
  • Prime + Probe

In Figure 2, the attacker will observe an increased access time for cache line 2. Since the attacker knows the code and access pattern of the victim, he knows that address X of the victim maps to cache line 2, and that the sensitive key-bit must be zero.

SystemPapers

April 3, 2021 at 10:40 pm
CS Research System

TEEPapers

April 5, 2021 at 10:07 am
Research Security SGX TrustZone

TrustZonePapers

April 5, 2021 at 10:08 am
CS Research Security TrustZone